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REMARKS 

A. INTRODUCTION 

The March 20, 2007 Office Action has been received and carefully considered. Claims 
1-25 are pending in the application, hi this response, no amendment has been made to the claims 
or other parts of the application. Applicant still believes that the application is in condition for 
allowance and notice thereof is respectfully requested. 

B. THE REJECTION UNDER 35 U.S.C. § 103 

On page 2 of the Office Action, claims 1-2, 11-13 and 25 are rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over Sit et al. (US Patent 6,349,336, hereinafter "Sit") in view of 
Fangman et al. (US Patent 6,687,245, hereinafter "Fangman"). On page 4 of the Office Action, 
claims 3-4 and 14-15 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Sit, in 
view of Fangman, and further in view of Fan et al. (US Patent 6,219,706, hereinafter "Fan"). On 
page 6 of the Office Action, claims 5-10 and 16-24 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Sit in view of Fangman and Fan, and further in view of Albert et al. (US 
Patent 6,687,222, hereinafter "Albert"). These rejections are respectfully traversed. 

Despite Applicant's criticism in the December 28, 2006 Appeal Brief (at p. 17-20), the 
Examiner appears to have again taken a flawed approach in the "new" grounds of rejection. 
Compared to the previous rejections based on Sit and Underwood (U.S. Patent 6,718,535), the 
current rejections replace Underwood with Fangman. However, the current rejections are just as 
deficient, if not more so, for at least the following reasons: (1) none of the cited references, 
including Fangman, teaches or suggests restricting FTP data to a single port on a firewall; and 
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(2) there is no suggestion or motivation to combine FTP functions with the "single port" feature, 

let alone a further combination of single-port FTP with Sit. 

As the Examiner acknowledged on page 3 of the Office Action, Sit does not mention 

using a single port on the firewall and does not support FTP. The Examiner asserts that 

Fangman discloses single-port communication through a firewall and FTP in the following 

passages: 

"Firewalls tend to support single port communication only initiated from 
the inside. Additionally, triangulated communications between IP 
telephones present a particular problem, referred to as the "triangle 

problem", described below." Fangman: col. 2, lines 22-26. 

"This [i.e., using Application Level Gateway as a proxy] has been done for 
a variety of protocols such as ICMP and FTP, and lately H.323 and SIP 
(two earlier VoIP standards), and solves the basic problem of public IP to 
private IP communication." Fangman: col. 2, lines 34-37. 

If Fangman is cited solely for the keywords "single port communication" and "FTP," the 

Examiner is absolutely right. However, if the Examiner meant to cite Fangman for the 

disclosure of single-port FTP through a firewall or somehow expects the combination of 

Fangman with Sit to do the magic of teaching or suggesting single-port FTP, it would not work. 

The phrase "single port communication" in the above-quoted passage has no relevance to 

FTP protocol at all. If one reads the entire paragraph at col. 2, lines 12-26, it is not difficult to 

understand that Fangman is comparing "single port communication only initiated from the 

inside" with VoIP protocols which "use pairs of ports for communication, initiated from both the 

inside and outside of the network" (emphasis added). It is quite clear that the "single port 

communication" does not include FTP at all because traditional FTP requires a pair of ports, just 

like the VoIP protocols as Fangman has correctly characterized. Therefore, in terms of the 

firewall issues discussed in Fangman, FTP is more like Voff protocols than any "single port 
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communication" protocols such as HTTP. Therefore, the phrase "single port communication," 

when put into its context in Fangman, does not suggest the restriction of data transfers to a single 
port on a firewall. Rather, it refers to those communication protocols that only requires one 
firewall port. FTP protocol is not one of those single-port protocols. 

The next passage (col. 2, lines 34-37), which the Examiner cites as disclosing "FTP," 
discusses interoperability between upper-layer protocols and Network Address Translation 
(NAT), which has no relevance to single port conmiunication through a firewall at all. 

The only other instance where Fangman mentions "single port" is in the paragraph at col. 
17, lines 6-23, where Fangman teaches assigning " a range of ports to the IP telephone 120 rather 
than a single port " (emphasis added). Note that Fangman is teaching the use of multiple ports on 
the firewall. Interestingly, the word "FTP" is also mentioned in the last sentence of the same 
paragraph — 

"In one embodiment, the range of port numbers assigned to the IP 
telephone 120 may include ports which are not reserved for use by other 
IP protocols, such as FTP, HTTP, etc., by the Internet Engineering Task 
Force (IETF)." 

Even more notably, the Examiner has cited to this same sentence on page 4 of the Office Action, 
apparently as part the argument that an ordinary skilled person would be motivated to combine 
Fangman with Sit. If the Examiner recalls, in earlier responses. Applicant has cited the same 
port number assignments made by IETF, wherein port numbers 20 and 21 are reserved for FTP 
communications. Now that the Examiner is also referring to the IETF port number assignments, 
the authoritativeness of which is undisputed, it is worthwhile to take a minute to reflect on this 
question — 7^ FTP traditionally a single-port or two-port protocoll 

It is well known standard that each FTP session involves two TCP ports, one for 
command and one for data. In the Background of the Invention, Applicant has pointed out that, 
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because of the multiple-connection requirement, a traditional FTP session through a firewall 

often requires the opening and closing of multiple random ports in the firewall to accommodate 

the data connections. That is, a firewall port randomly assigned for one FTP data connection 

does not remain open indefinitely. See present application: Figure 1 and paragraph [0016] 

("After requested data are sent to the passive FTP client system 2 by the FTP server 4 over the 

data channel, the FTP server 4 and the firewall 10 dynamically close the corresponding logical 

communication ports until the next data channel transmission."). 

That was the state of the art at the time of the present invention, and the Examiner has not 
made any attempt to contradict that. 

If the two-port FTP model was and still is the prevailing standard (as evidenced by IETF 
port number assignments), the Examiner has to face a simple yet critical question — Why would 
anyone skilled in the art ignore the standard, by restricting the data and command connections 
in an FTP session through a single port on a firewall? In view of the existing FTP standard, and 
without the hindsight from the present application, the concept of "single port communication" is 
simply incompatible and uncombinable with the standard FTP operations. 

The Examiner has been attempting to glue together the following pieces found in the 
cited references: (A) the physical structure disclosed in Sit, (B) "single port," and (C) "FTP." 
Applicant has acknowledged the physical similarity between the claimed system and the Sit 
system. However, with respect. Applicant does not believe the Examiner can ever find the 
"glue" needed to put (B) and (C) together. It is almost irrelevant as to where the Examiner finds 
the keywords "single port" and "FTP." The real issue is whether there has ever been any 
teaching, suggestion or motivation to combine these two elements, other than those found in the 
present appUcation. So far, the Examiner has found the keywords "single port" and "FTP" in 
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Epstein, Underwood, and Fangman. But, the obviousness grounds of rejection have been 
virtually unchanged. Instead of continuing the fruitless keyword searches, the examination of 
the pending claims should focus on the motivation to combine "single port" with "FTP." 

As stated earlier, the recognition of the problem (i.e., random port opening in FTP 
through a firewall) is an essential part of the present invention, which leads to a secured FTP 
architecture as recited in claim 1. Yet, there is no indication in any of the cited references that 
these problems were ever recognized or identified prior to the time of the present invention. Nor 
are these problems easily recognizable by a person of ordinary skill in view of the two- 
connection FTP model specified in the prevailing standard. Therefore, it is believed that the 
Examiner will never find any prior-disclosed motivation to combine single port communication 
with FTP. 

In view of the foregoing, Appellant respectfully submits that the Examiner still has not 
met the burden of proof in establishing the obviousness of claims 1-25. 
C. CONCLUSION 

In view of the foregoing, it is respectfully submitted that the present application is in 
condition for allowance, and an early indication of the same is courteously solicited. The 
Examiner is respectfully requested to contact the undersigned by telephone at the below listed 
telephone number, in order to expedite resolution of any issues and to expedite passage of the 
present application to issue, if any comments, questions, or suggestions arise in connection with 
the present application. 
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Please charge any shortage in fees due in connection with the filing of this paper, 

including extension of time fees, to Deposit Account No. 50-0206, and please credit any excess 

fees to the same deposit account. 



Respectfully submitted, 
HUNTON & WILLIAMS, LLP 



By: 



CeLi 

Registration No. L0214 



Hunton & Williams, LLP 
1900 K Street, N.W., Suite 1200 
Washington, D.C. 20006-1109 
Telephone (202) 955-1500 
Facsimile (202) 778-2201 



Dated: June 20, 2007 
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